Skip to content

Conversation

@cbrunschen
Copy link
Contributor

Also adds another text alignment option to stretch the text to fill its bounds horizontally.

The current code calculating the aspect ratio for text involves looping, calculating the width of text for a variety of decreasing aspect ratios until the text's width is less than the available bounds. However, this string width calculation performs the same loop over the text each time, finally multiplying by the candidate aspect ratio. That text width calculation thus really only needs to be done once. Further, instead of trying different aspect ratios, the ratio can simply be calculated directly by dividing the width of the bounds by the string's width. This also calculates a more accurate aspect ratio, rather than always resulting in an aspect ratio of (0.95)^n.

For example, when trying to fit a 101-pixel wide text into a 100-pixel wide space, the current code would result in an aspect ratio of 0.95, making the text 96 pixels wide, leaving 4 pixels unused; the new code will instead calculate the aspect ratio as 100/101 == 0.9900990099... , making the text use the full 100 available pixels.

This in turn allows us to easily calculate the ratio also if we want to not just schrink but also stretch the text to fill the available space, so we add that as another text alignment option, number 3 (three).

This PR also demonstrates this in the VFX family of layouts, where on the default Full view, the text "MUSIC PRODUCTION SYNTHESIZER" ("DYNAMIC COMPONENT SYNTHESIZER" on the VFX), the logo-like text "ensoniq", and the keyboard-specific markers "VFX", "VFX-SD", "SD-1" and "3 2 V O I C E" can now be made to fill their available space horizontally as they should, making it all look that much more like the real thing. One example from the sd132, before:

Screenshot From 2025-11-19 16-34-01

after:

Screenshot From 2025-11-19 16-33-18

and the real thing:

image

While still not perfect, the "after" at least has the corrects widths and horizontal alignments.

… ratio,

Also adds another text alignment option to stretch the text to fill its bounds horizontally.

The current code calculating the aspect ratio for text involves looping, calculating the width of text for a variety of decreasing aspect ratios until the text's width is less than the available bounds. However, this string width calculation performs the same loop over the text each time, finally multiplying by the candidate aspect ratio. That text width calculation thus really only needs to be done once. Further, instead of trying different aspect ratios, the ratio can simply be calculated directly by dividing the width of the bounds by the string's width. This also calculates a more accurate aspect ratio, rather than always resulting in an aspect ratio of (0.95)^n.

For example, when trying to fit a 101-pixel wide text into a 100-pixel wide space, the current code would result in an aspect ratio of 0.95, making the text 96 pixels wide,  leaving 4 pixels unused;  the new code will instead calculate the aspect ratio as 100/101 == 0.9900990099... , making the text use the full 100 available pixels.

This in turn allows us to easily calculate the ratio also if we want to not just schrink but also stretch the text to fill the available space, so we add that as another text alignment option, number 3 (three).

This PR also demonstrates this in the VFX family of layouts, where on the default Full view, the text "MUSIC PRODUCTION SYNTHESIZER" ("DYNAMIC COMPONENT SYNTHESIZER" on the VFX), the logo-like text "ensoniq", and the keyboard-specific markers "VFX", "VFX-SD", "SD-1" and "3 2 V O I C E" can now be made to fill their available space horizontally as they should, making it all look that much more like the real thing.
@cbrunschen cbrunschen marked this pull request as ready for review November 20, 2025 19:24
@Gurudumps
Copy link

Gurudumps commented Nov 21, 2025

Nice.
Q: Would this break existing lays?
For example where the width= boxes are wider than the text area due to not being able to see where the boundary is because it's invisible, and the text wasn't stretched due to the issue you mentioned in the old code?
If it is applied automatically then a whole bunch of lays will look very bad until they are fixed ;-)

Edit: Nevermind, I see it's an align="3" option which is new. Ok this solves the no-stretch issue.
Hopefully it gets into mainline rather being ignored like a lot of other cool stuff ;-)

btw, in your example case SD-1 logo thing, the way to do that is remove -1, place SD and place the 1 separately further over. The triangle can be done with a simple svg path that even AI can write in 2 seconds :-)

<!-- equilateral triangle with all sides 100 pixels -->
<element name="triangle">
<image state="0"><data><![CDATA[
<svg width="100" height="100" viewBox="0 0 100 100">
  <path d="M0,0 L100,0 L50,86.6 Z" fill="red" stroke="red" stroke-width="2"/>
</svg>
]]></data></image>
</element>

@cbrunschen
Copy link
Contributor Author

Nice. Q: Would this break existing lays? For example where the width= boxes are wider than the text area due to not being able to see where the boundary is because it's invisible, and the text wasn't stretched due to the issue you mentioned in the old code? If it is applied automatically then a whole bunch of lays will look very bad until they are fixed ;-)

The stretching is absolutely not applied automatically - it has to be explicitly requested by specifying align="3" in the layout file.

So, no, this will not break any existing layouts.

Edit: Nevermind, I see it's an align="3" option which is new. Ok this solves the no-stretch issue. Hopefully it gets into mainline rather being ignored like a lot of other cool stuff ;-)

btw, in your example case SD-1 logo thing, the way to do that

I'm not trying to recreate the actual SD-1 logo, because that would not be accepted, per this discussion on the layout for the ESQ-1. I am simply placing text in the corresponding place, specifically the name by which each keyboard is commonly known; and I want that text to take approximately the same amount of space as the log would. That's all.

(If I did want to put something there that looks a lot closer to the real logos, I have significantly better options available - they just won't be sent for inclusion in MAME because they would be rejected.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants